Systems and methods that facilitate management of add-on instruction generation, selection, and/or monitoring during execution

ABSTRACT

The subject invention relates to systems and methods that facilitate display, selection, and management of context associated with execution of add-on instructions. The systems and methods track add-on instruction calls provide a user with call and data context, wherein the user can select a particular add-on instruction context from a plurality of contexts in order to observe values and/or edit parameters associated with the add-on instruction. The add-on instruction context can include information such as instances of data for particular lines of execution, the add-on instruction called, a caller of the instruction, a location of the instruction call, references to complex data types and objects, etc. The systems and methods further provide a technique for automatic routine selection based on the add-on instruction state information such that the add-on instruction executed corresponds to a current state.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Divisional of U.S. patent application Ser. No.10/955,692, filed Sep. 30, 2004 and entitled SYSTEMS AND METHOD THATFACILITATE MANAGEMENT OF ADD-ON INSTRUCTION GENERATION, SELECTION,AND/OR MONITORING DURING EXECUTION, which is incorporated herein byreference.

TECHNICAL FIELD

The subject invention relates to industrial control systems and, moreparticularly, to systems and methods that create and manage add-oninstructions that are called by programs executing within industrialdevices.

BACKGROUND OF THE INVENTION

Industrial controllers are special purpose processing devices used forcontrolling (e.g., automated and semi-automated) industrial processes,machines, manufacturing equipment, plants, and the like. A typicalcontroller executes a control program or routine in order to measure oneor more process variables or inputs representative of the status of acontrolled process and/or effectuate outputs associated with control ofthe process. Such inputs and outputs can be binary, (e.g., “1” or “0,”“on” or “off,” . . . ), and/or analog, assuming a continuous range ofvalues. A typical control routine can be created in a controllerconfiguration environment that has various tools and interfaces wherebya developer can construct and implement a control strategy usingindustrial and conventional programming languages or graphicalrepresentations of control functionality. Such control routine can bedownloaded from the configuration system into one or more controllersfor implementation of the control strategy in controlling a process ormachine.

Measured inputs received from a controlled process and outputstransmitted to the process can pass through one or more input/output(I/O) modules in a control system. Such modules can serve in thecapacity of an electrical interface between the controller and thecontrolled process and can be located local or remote from thecontroller. Inputs and outputs can be recorded in an I/O memory. Theinput values can be asynchronously or synchronously read from thecontrolled process by one or more input modules and output values can bewritten directly to memory by a processor for subsequent communicationto the process by specialized communications circuitry. An output modulecan interface directly with a controlled process by providing an outputfrom memory to an actuator such as a motor, drive, valve, solenoid, andthe like.

During execution of the control routine, values of the inputs andoutputs exchanged with the controlled process can pass through memory.The values of inputs in memory can be asynchronously or synchronouslyupdated from the controlled process by dedicated and/or common scanningcircuitry. Such scanning circuitry can communicate with input and/oroutput modules over a bus on a backplane or network. The scanningcircuitry can also asynchronously or synchronously write values of theoutputs in memory to the controlled process. The output values from thememory can be communicated to one or more output modules for interfacingwith the process. Thus, a controller processor can simply access thememory rather than needing to communicate directly with the controlledprocess.

In distributed control systems, controller hardware configuration can befacilitated by separating the industrial controller into a number ofcontrol elements, each of which performs a different function.Particular control modules needed for the control task can then beconnected together on a common backplane within a rack and/or through anetwork or other communications medium. The control modules can includeprocessors, power supplies, network communication modules, and I/Omodules exchanging input and output signals directly with the controlledprocess. Data can be exchanged between modules using a backplanecommunications bus, which can be serial or parallel, or via a network.In addition to performing I/O operations based solely on networkcommunications, smart modules exist which can execute autonomous logicalor other control programs or routines. Various control modules of adistributed industrial control system can be spatially distributed alonga common communication link in several locations. Certain I/O modulescan thus be located proximate a portion of the controlled equipment, andaway from the controller. Data can be communicated with these remotemodules over a common communication link, or network, wherein allmodules on the network communicate via a standard communicationsprotocol.

In a typical distributed control system, one or more I/O modules areprovided for interfacing with a process. The outputs derive theircontrol or output values in the form of a message from a master or peerdevice over a network or a backplane. For example, an output module canreceive an output value from a processor via a communications network ora backplane communications bus. The desired output value is generallysent to the output module in a message. The output module receiving sucha message will provide a corresponding output (analog or digital) to thecontrolled process. Input modules measure a value of a process variableand report the input values to another device over a network orbackplane. The input values can be used by a processor for performingcontrol computations.

As noted above, a controller can execute routines to control machines,processes, manufacturing equipment, plants, and the like, and suchroutines can be created in a controller configuration environment anddownloaded to the controller for execution. In many instances, anend-user tailors code for a particular controller in order to control aspecific machine, process, equipment, plant, etc. in a desired manner.Within this code, the end-user can make one or more calls to one or moreadd-on instructions. Such add-on instructions, in general, respectivelyinclude and relate a set of re-usable routines, data parameters and/orstate data. When viewing logic or state data in a user interface (UI)for an add-on instruction routine, the end-user generally is unable todetermine which specific call to that routine is causing a particulardata value to be set to the current value. In addition, if there aremultiple calls, respective calls typically overwrite data visible in theUI, and the last call that wrote to the value before the UI is updatedis shown. This inability to distinguish which call caused the data valueto be set is a significant shortcoming with conventional systems.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order toprovide a basic understanding of some aspects of the invention. Thissummary is not an extensive overview of the invention. It is intendedneither to identify key or critical elements of the invention nor todelineate the scope of the invention. Its sole purpose is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description that is presented later.

The subject invention provides systems and methods that facilitatere-use of logic encapsulated in an add-on instruction(s) that are calledby a program(s) executing within an industrial device. Such add-oninstructions can be generated through a controller configurationenvironment to include and relate routines, various parameters and/orstate data (e.g., local tags) and can be protected by various knownsecurity techniques to mitigate unauthorized access. During execution,references (e.g., pointers) to complex data, objects and/or otherparameters can be passed to one or more of the add-on instructions. Forexample, structured data types or motion axes can be passed to theadd-on instructions by reference.

The configuration environment can provide for a relaxed mode, wherein auser can write logic for routines, define parameters or tags, and/orgenerate interfaces in any order including switching between writinglogic, defining parameters or tags, and generating interfaces at anytime without compromising the add-on instruction. In addition,associated help can be automatically generated, edited and provided tothe end-user. Add-on instruction generation can be facilitated throughessentially any industrial control language(s) to render an add-oninstruction in a similar and/or different industrial controllanguage(s). Furthermore, one or more add-on instructions can beassembled as a library.

The systems and methods employ a data context manager that tracks callsto add-on instructions and provides (e.g., as a list) context associatedwith such calls to a user, wherein the context can include at least oneor more of an instruction call(s), a caller(s), location(s), aninstruction instance(s), a result(s) of such execution, references tocomplex data types and objects, etc. A user can select a context from aplurality of contexts in order to observe execution for that contextand/or edit the context information.

The subject invention further provides a routine selection componentthat chooses a suitable set of control logic for an executing add-oninstruction based on a state of the add-on instruction or controller. Itis to be appreciated that an add-on instruction as well as other programmodules can be associated with various states. For example, an add-oninstruction can execute a particular set of control logic for normal,enable false, pre-scan, and post-scan states. In another example, anequipment phase program module can execute a particular set of controllogic for pre-state, running, holding, resetting, restarting, stopping,aborting, and fault states. In another example, a program module canexecute a particular set of logic for main and fault states. In yetanother example, a multiple method object program module can execute anyone of a set of user-specified sets of control logic based on a call toa particular user defined state. Depending on the program module and thestate, the routine selection component can obtain suitable logic forexecution, which can ensure proper pre- and post-conditions areavailable during execution of the add-on instruction. It is to beappreciated that the program modules, the set of control log, and/or theselection algorithm are extensible and not limited to any particularexample described herein.

To the accomplishment of the foregoing and related ends, the invention,then, comprises the features hereinafter fully described. The followingdescription and the annexed drawings set forth in detail certainillustrative aspects of the invention. However, these aspects areindicative of but a few of the various ways in which the principles ofthe invention can be employed. Other aspects, advantages and novelfeatures of the invention will become apparent from the followingdetailed description of the invention when considered in conjunctionwith the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary system that facilitates management ofadd-on instruction context information.

FIG. 2 illustrates an exemplary system that employs a routine selectioncomponent that facilitates automatic selection of a set of control logic(routine) based on state information.

FIG. 3 illustrates an exemplary system that presents context informationto a user as a list within a user interface.

FIG. 4 illustrates an exemplary method that manages add-on instructioncontext during execution.

FIG. 5 illustrates an exemplary method that automatically selects a setof control logic for execution based on state.

FIG. 6 illustrates an exemplary method for generating add-oninstructions.

FIG. 7 illustrates an exemplary Graphical User Interface thatfacilitates managing add-on instructions in accordance with the subjectinvention.

FIG. 8 illustrates an exemplary Graphical User Interface thatfacilitates add-on instruction library management in accordance with thesubject invention.

FIG. 9 illustrates an exemplary industrial control device that employs aroutine selection component.

DETAILED DESCRIPTION OF THE INVENTION

As utilized in this application, terms “component,” “system,”“controller,” “device,” “manager,” and variants thereof are intended torefer to a computer-related entity, either hardware, a combination ofhardware and software, software, or software in execution. For example,a component may be, but is not limited to being, a process running on aprocessor, a processor, an object, an executable, a thread of execution,a program, and/or a computer. By way of illustration, both anapplication running on a server and the server can be a component. Oneor more components can reside within a process and/or thread ofexecution and a component can be localized on one computer and/ordistributed between two or more computers.

The subject invention relates to systems and methods that facilitatedisplay, selection, and management of instruction-call data context formonitoring and/or changing values during execution. The system andmethods can track essentially all add-on instruction calls and providethe user with associated context, wherein the user can select aparticular context to observe data values and/or edit parametersassociated therewith. Monitoring of such information can be in thevisual context of the instruction logic or in state data and parameters.The context can include information such as instances of data forparticular lines of execution, the add-on instruction called, a callerof the instruction, a location of the instruction call, references tocomplex data and objects passed to the instruction, etc. The systems andmethods further provide automatic control logic selection based on stateinformation such that the control logic executed corresponds to thecurrent state of the add-on instruction. Moreover, add-on instructiondevelopment, packaging and execution by a user program can be performedvia any industrial control languages, including similar or differentlanguages for development, packaging and/or instruction calls.

The present invention is described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It may be evident, however, thatthe present invention may be practiced without these specific details.In other instances, well-known structures and devices are shown in blockdiagram form in order to facilitate describing the present invention.

FIG. 1 illustrates a system 100 that facilitates management ofinstruction-call data context for monitoring and changing values duringinstruction execution. The system 100 includes an instruction bank 110,which can be utilized to store add-on instructions that include andrelate one or more routines (control logic) with associated parameters(e.g., value parameters such as In and Out, and reference parameterssuch as InOut) and state data (e.g., local tags). It is to beappreciated that such routines can be generated in essentially anyprogramming language. Examples of suitable languages include industrialcontrol languages (e.g., structured text (ST), sequential function chart(SFC), functional block diagram (FBD), instruction list (IL), and ladderdiagram (LD)), C, C++, C#, Graphical Motion Language (GML), Java,Flow-Charts, etc., and/or any combination thereof. Such flexibilityallows a developer to select a language(s) suited to a particulartask(s) and provides for decomposition into logical elements andmodularization to construct instruction sets that can be re-used,mitigate errors, and increase programming and user efficiency.

An end-user program can call one or more add-on instructions stored inthe instruction bank 110 for execution within an industrial controller.For example, the end-user can write a program (routine or instruction)for a controller, wherein the program can include one or more calls toone or more add-on instructions in the instruction bank 110. When anadd-on instruction is called, a particular routine (control logic) ofthe add-on instruction can be executed based at least in part on theinstruction call, a state of the add-on instruction, and/or a mode ofoperation.

The system 100 further includes a routine selection component 120, whichcan facilitate determining which particular routine to execute. Forexample, multiple entry points can be associated with a program module,and the routine selection component 120 can facilitate logic executionof the multiple entry points based at least in part on state relatedinformation. By way of example, an add-on instruction program module canexecute a particular set of control logic for normal, enable false,pre-scan, and post-scan states. Depending on the state, the routineselection component 120 can facilitate selection of suitable logic forexecution. In another example, an equipment phase program module canexecute a particular set of control logic for pre-state, running,holding, resetting, restarting, stopping, aborting, and fault states. Inyet another example, a program module can execute a particular set oflogic for main and fault states. In still another example, a multiplemethod object program module can execute any one of a set ofuser-specified sets of control logic based on a call to a particularuser defined state. In general, there are a number of configurableoptions related to state and the routine selection component 120 canensure that suitable and/or desired pre- and post-conditions areavailable during execution.

It is to be appreciated that various parameters associated with anadd-on instruction can be passed by reference (e.g., pointer to memory)and can support essentially any tag type and/or object type. Passing byreference can provide for increased flexibility and power. It is to beappreciated that such parameters can be passed into an add-oninstruction via an N-dimensional (e.g., one, two, three . . . ), whereinN is an integer equal to or greater than one, array or matrix ofvirtually any size including a variable size. In addition, a referencecan be handled such that the size is automatically determined bysoftware and/or firmware, for example, based on levels of nesting and/orother factors. In many instances, such references cannot be overwrittenby the user logic and/or are not stored. However, the invention is notso limited. Local objects can be handled via a similar approach in orderto prevent unauthorized overwriting and/or other unauthorized actions.In addition, such data can include message, alarm, motion axis, motiongroup, coordinate system related data, for example.

FIG. 2 illustrates the system 200 that facilitates management ofinstruction-call data context for monitoring and changing values duringinstruction execution. The system 200 includes an instruction bank 210and a routine selection component 220. It is to be appreciated that theinstruction bank 210 and the routine selection component 220 can besubstantially similar to the instruction bank 110 and the routineselection component 120 described in connection with FIG. 1.

The system 200 further includes a data context manager 220. When anadd-on instruction call is added to a program, the data context manager230 (e.g., a software user interface) works with the configurationenvironment to determine where the add-on instruction is referencedand/or log associated information such as the call, the caller, variousparameters (as described herein), the instruction(s) called, referencesto complex data and objects passed to the instruction, etc. In addition,when multiple calls to instructions are made, the data context manager230 can determine and retain information related to one or more of thecalls. This information can be (automatically and/or on demand) providedby the data context manager 230 to the end-user via visual (e.g.,hardware and/or software indicators, user interface, e-mail, an instantmessage, paper . . . ) and/or audible (e.g., speaker, cell phone . . . )data.

With many conventional systems, the end-user is updated with a currentvalue based on a defined time duration, wherein the last instructioninstance executed during the duration typically determines the valueprovided to the end-user whereas prior calls and results are notprovided to the end-user. The data context manager 230 provides a novelapproach that mitigates this short coming. For example, the data contextmanager 230 can provide the end-user with essentially all the differentinstances of data including referenced objects such that there is noambiguity regarding which instruction call is changing data values. Withsuch data, a particular context can be selected for observation and/oredited. It is to be understood that an instruction definition can alsobe considered a data context that can be viewed and modified to setdefault values for parameters and local tags from that context. As such,when a new tag based on an add-on instruction type is created, the newlycreated tag can be initialized with the default values, and if aparameter is added, a new default value can be set into that member forany existing tags.

Furthermore, the data context manager 230 can provide associatedinformation such as the call(s), caller(s), instruction(s) called,parameters, references to complex data and objects passed to theinstruction, etc. The data context manager 230 can provide thisinformation as well as other information to the end-user via a UI 240,and the end-user can utilize the UI 240 to input information to create,modify, delete, etc. add-on instructions and/or other program modules,and associated parameters, state, etc. In one aspect of the subjectinvention, add-on instruction context information can be provided to theend-user via the UI 240 as a list 250 of all the different instances ofdata that can be animated, for example, in various logic editors and/ordata monitors. As depicted, list 250 can include M instances, wherein Mis an integer equal to or greater than one. For multiple calls from asimilar context, the location of respective calls can additionally belisted. This is illustrated in a list 260, which includes N instancesand associated locations. The end-user can select a particular entrywithin the lists 250 and 260 in order to observe and/or edit suchinformation. Moreover, it is to be appreciated that such data contextcan be maintained for all editors such that whenever a value is set, itis definitively setting the value in a particular context, and theinstruction definition can be viewed and modified to set default valuesfor parameters including passed references and state data from thatcontext as described above.

The UI 250 can be a graphical user interface (GUI), a command lineinterface, an Application Programming Interface (API), an industrialcontrol system environment, and the like. As such, the UI 250 canprovide a region and/or means to alter and/or manipulate graphicalobjects (e.g., icons, structures, text boxes, etc.) in connection withend-user applications and/or user interfaces. In addition, input regionscan be provided for entry of parameters, arguments, etc. that can beutilized to effectuate such entities. Moreover, one or more presentationregions can be provided to dynamically present interfaces to theend-user to provide a preview of any alteration, manipulation and/orchange. The GUI can include basic text and/or graphic regions thatincorporate dialogue boxes, static controls, drop-down-menus, listboxes, pop-up menus, edit controls, combo boxes, radio buttons, checkboxes, push buttons, and graphic boxes, for example. In addition,utilities such as vertical and/or horizontal scroll bars that facilitatenavigation and toolbar buttons to determine whether a region will beviewable, hidden, minimized, etc. can be employed.

The end-user can interact with at least the aforementioned regions toselect and provide information via various devices such as a mouse, aroller ball, a keypad, a keyboard, a pen and/or voice activation, forexample. Typically, a mechanism such as a push button or an enter key onthe keyboard/keypad can be employed subsequent to entering textualand/or voice information in order to invoke a response. However, it isto be appreciated that the invention is not so limited. For example,merely highlighting a check box can elicit an action. In anotherexample, a command line user interface can be employed to prompt (e.g.,via a text message on a display and an audio tone) the end-user toperform an action or provide information via alpha-numeric inputcorresponding to an option provided in the prompt or an answer to aquestion posed in the prompt. It is to be appreciated that the commandline interface can be employed in connection with a GUI and/or API.

FIG. 3 illustrates a system 300 that facilitates generating add-oninstructions and/or other programs. The system 300 comprises aninterface 310, which can be a graphical user interface (GUI), a commandline interface, an Application Programming Interface (API), anindustrial control system environment, and the like. The user interface310 can provide a developer with tools for creating and/or editingadd-on instructions, including associating various logic 320, parameters330, and/or state 340. It is to be appreciated that development can beachieved via standard industrial control languages such as structuredtext (ST), sequential function chart (SFC), functional block diagram(FBD), instruction list (IL), and ladder diagram (LD), as well as otherlanguages such as C, C++, C#, Graphical Motion Language (GML), Java,Flow-Charts, etc., and/or any combination thereof.

In one aspect, the developer can invoke an instruction generator 350 tocreate a package of one or more add-on instructions, whereinadd-instructions and/or packages thereof can be generated in essentiallyany programming language, including industrial control languages likeST, SFC, FBD, IL, and LD and various combinations thereof, whichprovides flexibility and allows a developer to select a language(s)suited to a particular task(s). In addition, the foregoing provides formodularization and re-use, which can improve programming and userefficiency.

Furthermore, add-on instructions can be assembled as a library. Thelibrary can be created via a markup language (e.g., Extensible MarkupLanguage (XML), Standard Generalized Markup Language (SGML), Hyper TextMarkup Language (HTML) . . . ), a binary file, an SQL database, etc.,wherein the controller language appears inside the language as contentof a routine. It is to be appreciated that individual add-oninstructions, a package of more than one add-on instruction, and/or alibrary of add-on instructions can be encrypted, encoded, passwordprotected, etc. in order to prevent unauthorized users from accessingthe instructions. In addition, properties associated with suchinstructions and/or libraries can be configured to provide and/or limitread, write, and execute privileges.

Moreover, in each language, the visualization of an add-on instructioncan be specific to that language based on its parameter configuration.For example, non-required, visible BOOL output parameters can bedisplayed as value-animated “bit-legs” displayed attached to theinstruction in ladder. In another example, pins in FBD can beautomatically laid out based on their order in the add-on instruction.

It is to be appreciated that creation of such add-on instructions and/orpackages and/or libraries of add-on instructions can be facilitated in arelaxed mode. Such relaxed mode allows the developer to write the logicfirst and define parameters and tags as desired, wherein the interfaceand data block can be automatically defined. Alternatively, thedeveloper can define interface specification and subsequently write thelogic. In yet another alternative, the developer can approach aninstruction from its data manipulation in the tag editor andsubsequently write its definition and/or logic. Moreover, the developercan switch between any these techniques without compromising aninstruction. In addition, associated help can be automatically generatedfrom the configuration of an instruction. Such help can be edited by thedeveloper to include additional text, if desired, and provided to theend-user.

Generated add-instructions can be saved in a storage component 360,assembled as a library in library 370 and/or transferred to anindustrial control system via an API 380. Additionally, add-instructionssaved within the storage component 360 (which can be substantiallysimilar to an instruction bank as described herein) and/or saved withinthe library 370 can be conveyed to the industrial control system via theAPI 380. Furthermore, the add-on instructions can track what othernested instructions they depend on when they are moved within projects,across projects, or between projects and libraries. In general, aproject is a container of programs and add-on instructions that isloaded to a controller. When copied into a project, the instructions itdepends on can be automatically copied. If an instruction's name is thesame as another instruction in the destination, mitigating handling canbe employed that allows the user to update the revision in thedestination or to resolve the collision. In particular, when a name isutilized by more than one instruction, the end-user can be provided withan option of updating the definition with the source revision, whereintags and other uses of the existing instruction are updated to the newrevision, thus preserving at least a portion of the current state data,wiring, and/or other configuration, and unneeded dependencies are notcopied.

In another aspect of the invention, when a copied add-on instructionincludes other (e.g., nested) instructions, the update can search thedestination project, the source project/library, and/or other librariesto find nested instructions to fill dependencies. If only oneinstruction is found, it can be automatically copied. If there aremultiple potential matches, the user can be provided with a message toresolve the matches. When only one instruction by a particular nameexists and such instruction is updated, associated instructions can beautomatically updated. It is to be appreciated that a set of locationsof libraries can be configured to describe which libraries to search fordependencies and which instructions are available for employment. Theselocations can be local, network, web server, and/or other type ofdrives. Information about who created an instruction and when, who lastchanged it and when, and what the origin library of an instruction canbe tracked regardless of where the instruction is copied. In addition,any or all such information can be protected or removed. For example,such information can be removed such that a library can be distributedwithout personal identity information.

The interface 310 can further be utilized by an end-user to generateend-user specific programs that call one or more add-on instructions.Such programs can be generated via industrial control languages such asST, SFC, FBD, IL, and LD and various combinations thereof, including alanguage(s) similar and/or different from the language utilized byparticular add-on instruction called by the program. Generation,storage, modification and/or employment can be achieved utilizing atechnique substantially similar to that described above in connectionwith generating add-on instructions and/or packages thereof. Briefly,the end-user can develop programs via the interface 310 and instructiongenerator 350, wherein such programs can call add-on instructions in thestorage component 360 and/or library 370. In addition, such programs canbe stored within the storage component 360 and/or conveyed to theindustrial control device for execution. Moreover, such programs can beretrieved from the industrial control device and modified.

FIGS. 4-5 illustrate methodologies, in accordance with an aspect of thepresent invention. While, for purposes of simplicity of explanation, themethodologies are shown and described as a series of acts, it is to beunderstood and appreciated that the present invention is not limited bythe order of acts, as some acts can, in accordance with the presentinvention, occur in different orders and/or concurrently with other actsfrom that shown and described herein. For example, those skilled in theart will understand and appreciate that one or more of the methodologiescould alternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, not all illustrated actsmay be required to implement the methodologies in accordance with thepresent invention.

FIG. 4 illustrates a methodology 400 that facilitates monitoring add-oninstruction logic. At reference numeral 410, a call to an add-oninstruction is recognized in the program configuration. For example, theadd-on instruction can be called by a program or another instruction. Itis to be appreciated that the program and the instruction call can begenerated in essentially any industrial control language (e.g.,structured text (ST), sequential function chart (SFC), functional blockdiagram (FBD), instruction list (IL), and ladder diagram (LD)) and/orother languages such as C, C++, C#, Graphical Motion Language (GML),Java, Flow-Charts, etc., In addition, the program language can besimilar or different from the programming language utilized for theadd-on instruction. In addition, a plurality of add-on instructions canbe serially and/or concurrently called by one or more programs executingwithin the controller. At reference numeral 420, context informationrelated to a call to an add-on instruction is obtained. Such informationcan include, for example, the call(s), a caller(s) of the call, aninstruction(s) called, an instance(s) of data, references to complexdata types and objects, etc.

At 430, the context information can be provided to the end-user. In oneaspect of the subject invention, the information can be provided as alist within a user interface or industrial control software environment.Such list can include essentially all instances of data that can beanimated within an editor or monitor. For multiple calls from a similartag, the location of respective calls can additionally be included inthe list. At 440, a user can select a particular entry within the listin order to observe and/or edit the context information (e.g., instancesof data for particular lines of execution, an instruction call, a callerof the instruction, a location of the instruction call, references tocomplex data and objects passed to the instruction, etc) associated withthe entry. Moreover, it is to be appreciated that such data context canbe maintained for all editors such that whenever a value is set, it isdefinitively set in a particular known context, and the instructiondefinition can be viewed and modified to set default values forparameters and local tags from that context, as described above.

FIG. 5 illustrates a methodology 500 that facilitates routine selectingbased on a state of an industrial controller. At reference numeral 510,a call for an add-on instruction is received. In one instance, such callcan be associated with a program executing within the controller. It isto be appreciated that the program and/or add-on instruction can bebased on essentially any industrial control language, including similaror different languages. At reference numeral 520, a current state of theadd-on instruction and/or controller is determined. Examples of suitablestates of the add-on instruction include: normal; enable false;pre-scan, and post-scan.

At 530, a routine is selected based on the state of the add-oninstruction and/or controller. By way of example, the add-on instructioncan have a routine that is executed during the normal scan. However, theadd-on instruction can also be associated with additional routines suchas override routines, for example, for execution in the other modes. Forexample, the add-on instruction optionally includes a routine(s) that isexecuted during initialization and a routine(s) that is executed duringcleanup of instruction states: pre-scan; post-scan; and enable false. Ingeneral, there are a number of configurable options related to thesestates. The present method facilitates ensuring suitable and/or desiredpre- and post-conditions are available during execution. At referencenumeral 540, the selected routine(s) can be executed. It is to beappreciated that parameters associated with the add-on instruction(e.g., complex data types and objects) can be passed by reference and/orcan support essentially any tag type and/or object type as describedherein.

FIG. 6 illustrates a methodology 600 that generates add-on instructionsand/or other program modules. At 610, one or more add-on instructionsare generated. Such instructions can be created via an interface such asa GUI, a command line interface, an API, an industrial control systemenvironment, and the like. The interface can provide a developer withtools for creating and/or editing add-on instructions, includingassociating various logic, parameters, and/or state. Such developmentcan be accomplished via any industrial control languages such as ST,SFC, FBD, IL, and LD and various combinations thereof. Generated add-oninstructions can be packaged and/or assembled in a library, and suchpackages and/or libraries can be based on similar or differentlanguages. Moreover, such libraries can be based on essentially anylanguage (e.g., as described herein) to facilitate dispersion andutilization.

At reference numeral 620, associated help can be automatically generatedfor an add-on instruction. Such help can be edited to include additionaltext, and/or be provided as graphical files, drawings, audio, html,external links, etc. At 630, the add-on instructions can be encrypted,encoded, password protected, configured (e.g., read, write and executeprivileges), etc. in order to prevent unauthorized users from access theinstructions. It is to be appreciated that creation of such add-oninstructions and/or packages and/or libraries of add-on instructions canbe facilitated in a relaxed mode, as described herein.

At 640, add-on instructions can be stored and/or utilized. It is to beappreciated that such add-on instructions can track nested instructionsand movement within, between and/or across projects and/or libraries.When copied into a project and/or library, the other instructions itdepends on can be automatically copied. In addition, if an instruction'sname is the same as another instruction in the destination, handling canbe employed that allows the user to update the revision in thedestination or to resolve the collision. If there are multiple potentialmatches, the user can be provided with a message to resolve the matches.In addition, when only one instruction by a particular name exists andsuch instruction is updated, associated instructions can beautomatically updated. It is to be appreciated that a set of locationsof libraries can be configured to describe which libraries to search fordependencies and which instructions are available for employment. Thelocations can be local, network, web servers, and/or other type drives.Information about who created an instruction and when, who last changedit and when, and what the origin library of an instruction can betracked regardless of where the instruction is copied. In addition, anyor all such information can be protected or removed such that a librarycan be distributed without personal information.

FIGS. 7 and 8 illustrate exemplary GUIs 700 and 800 that can facilitateemployment of the invention described herein. FIGS. 7 and 8 illustrateexemplary editors 700 and 800 that can be employed in accordance with anaspect of the subject invention. The editor 700 includes variousregions, utilities and windows such as, for example, a region fordisplaying add-on instruction folders, a language element toolbar, alogic editing window, a tag editing window, an instruction editingwindow, a new instruction window, and an instruction quick view window.The editor 800 depicts various software user-interfaces associated withadd-on instruction libraries such as a library manager window, a libraryinstruction property window and a new library, for example.

FIG. 9 illustrates an industrial device 900 in accordance with an aspectof the present invention. The industrial device 900 can be an industrialcontroller, a programmable logic controller (PLC), and the like. Assuch, the industrial device 900 can comprise one or more modules such asa processing module 910, a memory module 920, and an I/O module 930, anda power component 940 to energize components therein. The processingmodule 910 can be utilized to execute end-user programs and associatedadd-on instructions, which can be stored within an instruction bank 950(e.g., the instruction bank 110 and 210) of the memory module 920 orexternal to the industrial device 900. The I/O module 930 providescommunication with the environment. For example, an input channel can beemployed to receive analog and digital signals through sensors, switchesand the like to provide information indicative of state and/or relatingto a process, whereas an output channel can be utilized to convey a nextstate to an entity under the control of the controller. The device 900further includes a routine selection component 970 (e.g., the routineselection component 120 and 220 as described in connection with FIGS. 1and 2), which can be utilized to facilitate selection/management ofadd-on instruction calls as described herein.

What has been described above includes examples of the presentinvention. It is, of course, not possible to describe every conceivablecombination of components or methodologies for purposes of describingthe present invention, but one of ordinary skill in the art mayrecognize that many further combinations and permutations of the presentinvention are possible. Accordingly, the present invention is intendedto embrace all such alterations, modifications, and variations that fallwithin the spirit and scope of the appended claims.

In particular and in regard to the various functions performed by theabove described components, devices, circuits, systems and the like, theterms (including a reference to a “means”) used to describe suchcomponents are intended to correspond, unless otherwise indicated, toany component which performs the specified function of the describedcomponent (e.g., a functional equivalent), even though not structurallyequivalent to the disclosed structure, which performs the function inthe herein illustrated exemplary aspects of the invention. In thisregard, it will also be recognized that the invention includes a systemas well as a computer-readable medium having computer-executableinstructions for performing the acts and/or events of the variousmethods of the invention.

In addition, while a particular feature of the invention may have beendisclosed with respect to only one of several implementations, suchfeature may be combined with one or more other features of the otherimplementations as may be desired and advantageous for any given orparticular application. Furthermore, to the extent that the terms“includes,” and “including” and variants thereof are used in either thedetailed description or the claims, these terms are intended to beinclusive in a manner similar to the term “comprising.”

1. A method that facilitates instruction-call data context management,comprising: retaining data context associated with a call to an add-oninstruction; providing the data context as a selectable entry within alist of context information to a user; and selecting the data context ofthe add-on instruction from the list to observe data and edit parametersassociated with the add-on instruction.
 2. The method of claim 1,further comprising displaying the add-on instruction call in a languagedetermined by its parameter configuration.
 3. The method of claim 1,further comprising using the data context in order to definitively set avalue in a particular context.